In trusted computing systems, in order to assure appropriate trust and/or security, it is possible for software to check every parameter of every cryptographic key that the software uses, before the software uses it. This can be automated but is inconvenient for software developers and typically requires the developers to have a detailed understanding of what makes a cryptographic key safe or unsafe. While it is desirable for software developers to have such detailed understanding, it may not always be a practical expectation, and there remains a need for convenient ways to instill confidence that the operation of a computing system, in terms of the cryptographic keys it uses, is trustworthy.
Some trusted computing systems contain a component, known as a Trusted Platform Module (TPM), which is at least logically protected from subversion. Such components have been developed by the companies forming the Trusted Computing Group (TCG). The TCG develops specifications in this area, for example the “TCG TPM Specification” Version 1.2, which is published on the TCG website https://www.trustedcomputinggroup.org/. The implicitly trusted components of a trusted computing system enable measurements of the trusted computing system and are then able to provide these in the form of integrity metrics to appropriate entities wishing to interact with the trusted computing system. The receiving entities are then able to determine from the consistency of the measured integrity metrics with known or expected values that the trusted computing system is operating as expected. In some such trusted computing systems, the parameters and associated algorithms employed by the trusted components are relatively standard, and well understood, which, to a large degree, obviates the requirement to check every parameter of every cryptographic key that software uses. However, future TCG TPM Specifications may provide the capability for different manufacturers or owners or users to load different algorithms and different parameters settings for the same algorithms into a trusted component. Then, different trusted components might use different algorithms and/or different algorithm parameters, possibly interchangeably on demand, to enact particular cryptographic operations, such as encryption or decryption. Such a development would once again place greater onus on software developers to have a detailed understanding of what makes a cryptographic key safe or unsafe.